1 



PROGRAMMING STATION GENERATING A COMPACTED PROGRAM AND 
AUTOMATION EQUIPMENT USING SUCH A PROGRAM 

This invention relates to a programming station 
generating a compacted program using a single 
hierarchised and object oriented language to program an 
automation application and automation equipment using 
5 such a program. 

In the following, a programming station refers to 
computer equipment, particularly a PC type personal 
computer, that can be connected to an automation 
equipment. In the following, automation equipment 

10 refers to a programmable logic controller, an 
instrumentation / control station, a numerical control 
or other equipment that can contain and execute an 
application program controlling an automation 
application. For example, this automation application 

15 may be in the domain of industrial process automation, 
building automation or instrumentation / control of 
electrical distribution networks. 

This type of automation equipment is composed of a 
central unit and one or several input-output modules 

2 0 connected to sensors and preactuators of the automation 
application to be controlled. 

The central unit comprises at least one processor, 
a non-volatile memory, usually not modifiable (ROM) or 
modifiable (EEPROM) containing the manufacturer's 

25 program also called the proprietary operating system, 
expressed in a language specific to the manufacturer of 
the automation equipment, a RAM memory and an input - 
output manager communicating together through a back 
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plane bus. A first area of the RAM memory (also called 
the volatile memory) contains the user's program, and a 
second area contains the data, and particularly images 
of the states of input -output modules and constants 
5 related to the user's program. 

The user's program, also called the application 
program, monitors or controls an automation application 
by means of inputs -outputs controlled by this 
application program. The designer creates this program 

10 and it is written in one or several graphic automation 
languages particularly including Ladder Diagrams called 
Ladder language in the following, Sequential Function 
Charts or Grafcet language called SFC language in the 
following, Function Block Descriptions called FBD 

15 language in the following, or in IL (Instruction List) 
or ST (Structured Text) type automation text languages. 
These automation languages are preferably conform with 
standard IEC 1131-3 to facilitate programming by an 
automation designer who is not necessarily familiar 

20 with computer languages. These languages can be used 
on programming stations that may or may not be 
connected to the automation equipment to be programmed. 

At the moment, application programs created using 
graphic automation languages conform with standard 

25 IEC 1131-3 cannot be exchanged between automation 
equipment made by different manufacturers with 
manufacturer programs based on different manufacturer 
languages and different programming workshops. After 
the designer of an automatic control has produced the 

3 0 application program in one of the standard languages, 
the programming station or the automation equipment on 
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which the designer is working translates this program 
into a binary file dependent on the specific language 
of the manufacturer of each automation equipment. Only 
this file is stored in the automation equipment so that 
5 it can be executed by the automation equipment 
processor . 

A third party connected to the automation 
equipment through a PC type programming station without 
a decompilation program on his station will be unable 

10 to understand the automation application program in 
binary format stored in the automation equipment and 
will not be able to make any modifications unless he 
has installed a plurality of programming programs 
specific to the manufacturer on his station 

15 (programming workshop) . One solution would be to store 
the application program on the automation equipment in 
source language, but the size of this source program 
would often be incompatible with the memory size of the 
automation equipment . 

2 0 The first purpose of the invention is to obtain a 

programming station using a single language that can be 
edited by any editor to generate automation application 
programs in a compacted format, regardless of the 
graphic language used to describe operation of the 

25 automation equipment. 

This purpose is achieved using a station for 
programming an automation application designed to be 
executed in an automation equipment, the programming 
station comprising a memory containing a set of one or 

30 several description files, each description file 
describing a part of the application and being 
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expressed in a single, hierarchised and object oriented 
language. The programming station uses a compression 
program that generates a file in the compacted format 
for each description file, the contents of the 
5 compacted file being sufficient for the description of 
the part of the application considered, and in that it 
uses a loading program to store each compacted file in 
a memory in the automation equipment . 

According to one feature, the programming station 
10 uses a decompression program to generate a description 
file in a single, hierarchised and object oriented 
language describing part of the application, from a 
compacted file stored in the automation equipment 
memory . 

15 According to another feature, the single, 

hierarchised and object oriented language is the XML 

(extended Markup Language) language. 

According to another feature, the set of one or 

several description files contains an application 
20 program description file, an application input-output 

description file, and an application data description 

file. 

According to another feature, the compression 
program comprises a step to reduce tags contained in a 

25 description file expressed in the XML language by 
application of a specific stylesheet and a step to 
execute a compaction algorithm adapted to XML files. 
The decompression program comprises a step to execute a 
decompaction algorithm adapted to XML files and a step 

3 0 to recreate source tags contained in a description file 



5 



expressed in the XML language, by application of a 
specific stylesheet. 

According to another feature, the programming 
station includes an XML handler (Hndlr) in a non- 
5 volatile memory dialoguing through notifications 
firstly with a management module of the tree structure 
representative of the automation application expressed 
in the XML language, and also with a plurality of 
database managers, each specific to part of the 

10 automation application stored in one of the databases. 

Another purpose of the invention is to propose 
automation equipment capable of importing or exporting 
automation applications that it executes on a 
programming station on which an XML editor or display 

15 unit is installed. 

This purpose is achieved by the fact that the 
automation equipment comprises a memory containing an 
automation application program in the form of a binary 
file executable by the automation equipment. The 

20 automation equipment stores the executable binary file 
in its memory, together with one or several files in a 
compacted format output from the description file(s), 
in which the contents are sufficient for a description 
of the application, starting from one or several 

25 description files describing all or part of the 
application and expressed in a single, hierarchised and 
object oriented language. 

According to one feature, the single, hierarchised 
and object oriented language is the XML (extended 

3 0 Markup Language) language. 
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According to another feature, the automation 
equipment comprises translation means in order to 
convert application description files expressed in the 
XML language into a binary file that can be executed by 
5 the automation equipment. 

According to another feature, the automation 
equipment comprises means of decompressing a file in 
compacted language to a description file in XML 
language, by using a specific stylesheet. 
10 The proposed XML grammar can be used to define a 

single exchange format for the five graphic or text 
languages (LD, SFC, FBD, IL, ST) conform with standard 
IEC 1131-3. Automation application data will also be 
described in the XML language and thus can be easily 
15 imported or exported to different third party software 
(electrical CAD, Supervision, etc.). 

XML language files will also be transformed into 
other XML language files with a different grammar, 
using a stylesheets mechanism (XSLT : extensible 
2 0 Stylesheet Language Transformation) . For example, it 
will be very easy to make a gateway between data in an 
automation application and a spreadsheet software such 
as Microsoft Corporation's EXCEL. 

Parts of applications generated in the XML 

2 5 language will be displayed by WEB search, display, edit 

utilities (browsers) such as Internet Explorer, which 
include XML display units in the basic version. 
Another advantage of the proposed solution is that it 
offers a formal grammar for exchanging automation data. 

3 0 Therefore, the solution proposed herein offers many 

advantages for exchanging automation data. 
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Other features and advantages of this invention 
will become clearer after reading the following 
description with reference to the appended drawings in 
which : 

5 - figure 1 shows a diagrammatic view of a 

programming station on which an XML manager is 
installed to import or export description files from a 
single language application to one of the graphic 
languages, 

10 - figure 2 shows an example of the memory 

organization of the grammar used to describe an 
automation application in the single language according 
to the invention, 

figure 3 shows a software component that 
15 forms a tag index generator to produce index files, 

figure 4 shows details of the process for 
compression of a description file to a compacted file. 

The invention consists of describing an automation 
application using a single, hierarchised and object 

2 0 oriented language starting from a grammar of this 

language defined specifically to translate the 
automation application written in one or several 
graphic automation languages conform with standard 
IEC1131-3 and to store a compacted file output from 
25 this description in the automation equipment. In the 
embodiment presented, this single, hierarchised and 
object oriented language may be the XML (extended 
Markup Language) language. The description is text 
only (no binary information) . It is independent of the 

3 0 implementation and must respect XML standards. The XML 

description of an automation application may be stored 



in full or in part in the form of a set of one or 
several description files. These files may be imported 
and/or exported to and from third party software . Each 
descriptive object of the application in the XML 
5 language is assigned firstly XML tags that are words 
enclosed between "less than" (<) and "greater than" (>) 
signs, and also by attributes (in the form 
name=" value") . Therefore the entire application can be 
described using tags and attributes . The tags are only 

10 used to delimit data elements and the application that 
reads the data interprets these data completely. These 
tags are usually composed of words that are 
understandable even for a user who is not a person 
skilled in the art. 

15 Normally an automation application is described by 

several description files comprising an application 
program description file, an application inputs -outputs 
description file, and an application data description 
file. 

2 0 Appendix 1 contains one specific grammar for the 

translation of an application program description 
written in Ladder graphic language, into the XML 
language . 

The description in the Ladder language is 

2 5 structured into contact networks, and each network is 

described line by line working from the top downwards. 
Each line is described from the left towards the right. 
Each line begins with the left rail (to the left of the 
view of the Ladder network) and terminates on the last 

3 0 graphic element described . Each line contains a list 

of standard graphic elements in the Ladder language: 
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contacts, coils, horizontal link, vertical link, 
function block, etc. Graphic coordinates are relative 
to the position of objects in the table of rows and 
columns of a graphic display. 
5 Line 10 in the grammar shown in appendix 1 

corresponds to a graphic representation of an 
application in Ladder language, and defines that an 
"LDSource" application in Ladder is composed of a 
Ladder network (networkLD) and from zero to n 

10 (indicated by the * sign) text boxes (textBox) defined 
in lines 59 to 61. A Ladder network (networkLD) is 
composed of one or several type lines (typeLine) 
(indicated by the + sign) and a link with zero to n 
function blocks (FBLink) . As described in line 50 in 

15 appendix 1, the link with at least one function block 
(FBLink) is composed of two position objects 
(obj Position) , the coordinates of these position 
objects defining a start position corresponding to the 
"from" attribute (from, line 51) and an end position 

20 corresponding to the "to" attribute (to, line 52) . As 
described in line 13 in appendix 1, the type line 
(typeLine) object is composed from zero to n of a 
combination of the following objects, either an empty 
line (emptyLine) , or a contact (contact) , a horizontal 

25 link (Hlink) , a vertical link (Vlink) , a coil (coil) , a 
control (control) , a short circuit (shortCircuit ) , an 
empty cell (emptyCell) , a function block call (calls) , 
an FFB expression (FFBExpression) , a comparison block 
(compareBlock) and an arithmetic operation block 

30 (operateBlock) , at will. 
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The type line (typeLine) object has a text label 
attribute. The attribute of the contact object defined 
on line 18 is the type of contact that defines the 
contact type, open, closed, upwards, downwards, in the 
5 form of an enumeration (openContact , closedContact , 
Pcontact, Ncontact) and the name of the contact 
variable (ContactVariableName) that is of type text. 
Line 23 defines the horizontal link (Hlink) object that 
has a number of cells (numberCell) through which the 

10 horizontal link (Hlink) passes, as an attribute. Lines 
26 and 27 in appendix 1 define the coil (coil) object 
that can be either of type coil (Coil) , inverse coil 
(not Coil) , coil for setting to one (setCoil) , reset 
coil (resetCoil) , transition hash coil (hashCoil) used 

15 only in association with the SFC language, rising front 
coil (Pcoil) , falling front coil (Ncoil) and the name 
of the coil variable (coilVariableName) that is of type 
text. The control object (control) defines the control 
type, either jump (jumpCoil) or return (retCoil) on 

20 lines 35 to 37. The short circuit object 

(shortCircuit) is defined on line 38 as being the 
combination of vertical link (Vlink) objects and one of 
the horizontal link (Hlink), contact, coil (coil), 
calls (calls) , comparison block (compareBlock) elements 

25 at will. A call block (calls) as defined on line 39, 
contains an instance of an object ( instanceOb j ) , a 
parameter type (typeParam) and a call description 
(descriptionCall) . The parameter type (typeParam) and 
the call description (descriptionCall) may or may not 

3 0 be assigned different values, since they are optional 
as indicated by the "?" sign. The value of the 
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parameter type is defined on line 41 as being a boolean 
value equal to "0" or "1" (enEnO) . Line 43 defines the 
description of a call (descriptionCall) as being 
composed of a list of inputs (inputListFBD) to the 
5 function block (FBD) that are lists of formal 
parameters and effective parameters (see lines 45 and 
46) and a list of outputs (outputListFBD) from the 
function block (FBD) . The text boxes are defined by 
the position of the text box object and by its 

10 dimensions in height and width. 

For sections written in Ladder language, each 
application program may be described using the grammar 
corresponding to the Ladder graphic language. Each 
grammar is used to define a hierarchy between objects 

15 and to represent an automation application in the form 
of a graphic tree structure (3 0) in the programming 
station RAM memory. 

Thus, as can be seen in appendix 1, the root of 
the tree is composed of the source application 

2 0 (LDSource) to which one or several sons are attached, 
namely the network (networkLD) and possibly one or 
several text boxes (textBox) . The network has one or 
several sons composed of type line (typeLine) and FB 
link type (FBLink) objects. The line type (typeLine) 

2 5 object has a son consisting of the empty line 

(emptyLine) , or one of the following elements: contact 
(contact) , vertical link (Vlink) , horizontal link 
(Hlink) , coil (coil) , control (control) , short circuit 
(shortCircuit) , calls (calls) , comparison of blocks 

3 0 (compareBlock) , execution of block (operateBlock) , FFB 

expression (FFBExpression) . 
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Appendix 2 defines a grammar specific to the 
translation of a description of an application in the 
SFC graphic language, into the XML language. 

Line 11 of the grammar shown in appendix 2 defines 
5 that the description of an application (SFCSource) into 
the SFC language comprises a header (SFCHeader) and is 
structured into pages (SFCPage) that correspond to 

screen pages displayed by an SFC language editor. The 

U 

O header (SFCHeader) has the task (task) and the graph 

10 name (graphName) as attributes. Each page may contain 
UJ one or several SFC networks (networkSFC) . Each network 

LI contains a list of "object" elements chosen among the 

following standard graphic elements of the SFC 
O language: step (step), jump (jump), transition 

fl : 

jT 15 (transition) , link between steps and transition 

ji 1 (SFCLinkObject) , comment (commentSFC) , link between 

fy graphs (linkSFC) . The graphic coordinates of the 

different jump, step or transition type objects are 
defined by a position type object (obj Position) 

2 0 defining the row/column position of the corresponding 

object (jump, step or transition) in the table. A step 
type object (step) is defined by one or several actions 
in which the attributes are defined on lines 23 and 24 
in appendix 2. Transitions are also defined by 
25 transition conditions (transitionCondition) on line 28. 
Link between graphs type objects (linkSFC) are composed 
of two position objects (obj Position) , the coordinates 
of these position objects defining a start position 
corresponding to the "from an object type" 

3 0 (typeObj ectFrom) , line 45 attribute and an end position 

corresponding to the "to an object type" attribute 
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(typeObjectTo) , line 54. Each of these two attributes 
is chosen from one of the following objects: initial 
step (initialStep) , step (step) , macro step 
(macroStep) , internal step (stepln) , transition 
(transition, A branch (Abranch) , P branch (Pbranch) , A 
joint (Ajoint) , P joint (Pjoint) , and for the "to" 
attribute, chosen from the previous objects and the 
jump object (jump) . 

The hierarchy of the SFC language is as follows. 
The root of the tree structure is the source object 
(SFCSource) that itself has the header (SFCHeader) and 
the page (SFCPage) as sons. The page has the network 
(networkSFC) as son, and the sons of the said network 
are the step (step) , the jump (jump) , the transition 
(transition), the SFC object link (SFCLinkObj ect ) , the 
SFC comment (comment SFC) , and the SFC link between 
graphs (linkSFC) . 

Similarly, appendix 3 shows a grammar specific to 
the translation of a description of an application in 
an FBD graphic language into the XML language. 

Each network in the FBD language contains a list 
of standard graphic elements in the FBD language: the 
function block (FFBBlock) , text box (textboxFBD) , label 
(labelObj ect) , comment ( comment Ob j ect FBD) , link 
between blocks (linkFBD) and jump instruction 
(jumpObject) . Each element is defined in accordance 
with lines 12 to 39 in appendix 3. The graphic 
coordinates are relative to the row/column position of 
objects in the table. 

The hierarchy between objects defined in this 
grammar is as follows. The root is composed of the FBD 
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source (FBDSource) , which is composed of one or several 
FBD networks (networkFBD) . Each network is composed of 
one or several of the following son elements: the 
block (FFBBlock) , the text box (textBoxFBD) , the label 
5 (labelObject) , the jump ( jumpObj ect ) , the comment 
(commentObjectFBD) and the link (linkFBD) . 

The grammar description files (4 02, figure 2) are 
organised as follows. An automation application may be 
broken down into three main parts, its program, its 

10 data and its inputs/outputs. According to the 

invention, the grammar of each of these parts is 
described in a "Document Type Definition" file in the 
".dtd" format (for example program. dtd for the 
application program file, datas.dtd for the data file, 

15 IOConf.dtd for the inputs /outputs configuration file) 
or in a "Schematic" file in the " .xsd" format. In the 
following, we will talk about ".dtd" files but they may 
be replaced by ".xsd" files which are equivalent. 
Thus, when the "datas.*" type notation is used in 

2 0 figures 2 and 3, it refers to a data file that may be 

either a "datas.dtd" or "datas. xsd" type file. Each 
part of the application program may itself be broken 
down into sub-parts each forming the subject of a 
".dtd" (or ".xsd") description file. For example, the 
25 program file (program. dtd) may include source files 
(LDSource.dtd, SFCSource . dtd and FBDSource . dtd, as 
shown in figure 3) that contain grammars of the 
different graphic automation languages of the Ladder 
diagram, sequential function chart (SFC) and function 

3 0 block (FBD) types. 
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".dtd" and ".xsd" grammar files are files specific 
to the manufacturer and contain a description of the 
different grammars. Thus the "Application" file 

(figure 2) contains the (commonElements . *) file that 
contains elements common to the automation application, 
namely the application name, the production date of the 
application or the version, the version number and 
comments. The "Configuration" file contains 

configuration files for inputs /outputs (IOConf.*) and 
for the logical configuration (LogicConf . * ) 
respectively. The "Instance", "DDT", "DFB types" files 
contain the description of data, instance, DDT, FB type 
in the form of (data, DDTSource . * , FBDSource . * , 
FBSource.*) files. The "Program" file contains the 
(LDSource . * , SFCSource . * and FBDSource.*) source files 
that contain the description of each grammar specific 
to each normal graphic language described in appendices 
1 to 3 respectively. The "Animation tables" folder 
contains the description of animation tables, that 
includes the common elements (commonElements.*) and 
data (datas.*) files. The "Operator screens" folder 
contains descriptions of operation screens composed of 
common element (commonElements.*) and data (datas.*) 
files. These different grammar files of the ".dtd" 
type define the structure of XML files. An XML file of 
an application represents an instance of the grammar 
defined in the corresponding ".dtd" file. XML 
description files (401) are specific to the automation 
application considered. The principle of 

correspondence between these two types of files is 
defined by the XML standard VI . 0 in accordance with the 
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Document Object Model (DOM) . The document object model 
DOM is a set of standard call functions for 
manipulating XML files, starting from the 
manufacturer's automation graphic languages. 
5 Correspondence between XML files and application 

databases is as follows: 

An automation application is stored in binary 
format on a programming station that can be connected 
to an automation equipment. This automation 

10 application according to prior art was developed by the 
user who used an editor (5) for graphic languages IEC 
1131-3 using a software component subsequently called a 
manager (Mngl, Mng2 , etc.) to store user inputs in 
several databases; for example one database (Dbl) for 

15 the application program, one database (Db2) for 
application data and one database (Db3) for the 
configuration of application inputs/outputs, (Dbl) and 
(Db2) being shown in figure 1. The description of the 
application in the XML language according to the 

2 0 invention is completely independent of its 
implementation in such manufacturers' databases. A 
particular software component has been developed in 
order to achieve this independence; this component 
forms an automatic tag index generator represented in 

2 5 figure 3 and is referred to in the following as the 

GenlnTag (25) component. 

The GenlnTag software component (2 5) generating 
tag indexes must be executed to produce index files in 
order to make the correspondence between the XML 

3 0 graphic tree structure (3 0) representing the automation 

application in the language according to the invention, 
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and database structures (Dbl, Db2) . This GenlnTag 
component extracts keywords (elements and attributes) 
from the different files (4 02) that define XML 
(."dtd") grammars for the program, data, the input- 
output configuration in the XML language, in order to 
generate indexes organized in several files, for 
example four files (II, 12, 13, 14) in figure 3, each 
containing one or several files of index constants used 
by the different managers (Mngl, Mng2 , ...) . The 
GenlnTag component reads definition files for the 
document type ".dtd" or diagram type " .xsd" - and 
generates the different index files. These index files 
create the correspondence that makes it possible to use 
application description databases (Dbl, Db2) according 
to prior art . They are stored in non-volatile memory 
on the programming station. 

The programming station includes an XML Handler 
Hndlr (20) program in non-volatile memory. The XML 
handler Hndlr (2 0) is a software component developed in 
the C + + language that can be used through a COM 
interface. It encapsulates and uses the services of a 
DOM Parser Prsr and offers high level services for the 
management of the XML graphic tree structure (3 0) . The 
XML Handler Hndlr (2 0) makes it possible for the 
programming station to create the tree structure (3 0) 
representative of the application from description 
files (401) using grammar files (402) , or to create 
this structure starting from requests made by managers 
(Mngl, Mng2 , ...) of application databases. It uses the 
different managers that call the services of the XML 
Handler Hndlr (20) using index files (II to 14) 
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generated by the GenlnTag component (2 5) . As shown in 
figure 1, each part of an application, for example an 
application program (Dbl) , application data (Db2) , is 
managed by a specific manager (for example Mngl for the 
application program, Mng2 for the data) . The XML 
Handler Hndlr (20) comprises the DOM Parser Psrs which 
is a software component in the C++ language, and also 
an export routine and an import routine. 

The export routine writes the automation 
application information into an XML file, and the 
import routine reads the automation application 
information into an XML file. Each of the managers 
dialogs with the different services of the XML handler 
Hndlr (20). The specific managers (Mngl, Mng2 , etc.) 
use index files (II to 14) . In one advantageous 
variant of the invention, the export routine 
incorporates a compression program (60) to generate a 
compacted form (501) of the XML data file (401) once 
the XML file has been produced. The programming 
station then uses a loading program in order to store 
each generated compacted file (501) in the automation 
equipment memory (50) . 

Thus, due to its compacted form (501) , the 
automation application in source language will occupy 
less memory space and it will be possible to load it 
entirely onboard the automation equipment, whereas in 
prior art it was impossible to load the entire 
application in source language onboard the automation 
equipment due to the amount of memory occupied by the 
application in the source language. Furthermore, as 
shown in figure 4, the compacted file (501) is stored 
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in the memory (50) of the automation equipment at the 
same time as the binary data file (502) resulting from 
a conventional compilation of the XML file (4 01) by the 
programming station compiler (7) . The file (502) 
output from this compilation can be used directly by 
the proprietary operating system of the automation 
equipment . 

Only the application in object language 
(proprietary) had a size compatible with the memory 
resources of the automation equipment and an 
application in object language cannot be used on a 
programming station without firstly being decompiled by 
a decompiler corresponding to the proprietary language 
of the operating system. Therefore, it was not 
possible for a programming station without anything 
installed on it to be connected to automation equipment 
and to retrieve an automation application described in 
a graphic language. Thus, by combining the use of 
grammars in the XML language and compaction 
stylesheets, it is possible to generate one or several 
compacted files (501) describing the application that 
are sufficiently small so that they can be loaded 
onboard the automation equipment at the same size as 
the executable file (502) . Each file (501) can be 
unloaded on a programming station to be decompressed 
and then used by any software using the XML language . 

The compression program (60) does the compression 
in two steps are shown in figure 4 : 

a first step to reduce tags using a 
transformation mechanism (604) (XSLT (extensible 
Stylesheet Language Transformation) processor) to 
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transform tags in the XML file (401) by applying a 
stylesheet in the XSL (extensible Stylesheet Language) 
standard to this XML file. This specific XSL 

stylesheet (601) created specially for the needs of the 
5 invention, is partially described as an example in 
Appendix 6. It is a means of reducing the length of 
tag names and therefore supplying a translation in 
reduced XML language for each tag in the XML file 
(401) . The stylesheet is applied in the programming 

10 station and it provides a reduced XML file (602) at the 
output, temporarily stored so that it can subsequently 
be used by a compaction algorithm that is executed on 
the programming station. Appendix 4 contains an 
example of an XML file (401) and appendix 5 contains 

15 the same example in the form of a reduced XML file 
(602) . 

a second step in the execution of a 
compaction algorithm (603) like that in particular 
marketed under the term "Xmill", adapted to documents 

20 in the XML language. This algorithm starts with the 
reduced XML file (602) and produces a compacted file 
(501) . This type of compaction algorithm takes 

advantage of knowledge of rules of the XML language, 
particularly rules inherent to XML documents, and 

25 especially rules about tags (start tag, end tag, no 
nesting of tags) to optimise compression. 

As mentioned above, appendix 6 only contains a 
fragment of a specific stylesheet (601) sufficient to 
understand the mechanism for reducing the size of tags 

3 0 in an XML file. Considering only a few examples chosen 
in the part shown in Appendix 6, the "company" tag will 



thus be reduced to tag "cl" (see page 27 lines 68-70) 
by application of the stylesheet. Similarly, the 
"dateTime" tag will be reduced to tag "d2" (see page 28 
lines 37-39) , the "address" tag will be reduced to tag 
5 "a2" (see page 29 lines 12-14), etc. Thus, all tags 
in an XML file can be reduced similarly to make it easy 
to optimise the size of a reduced XML file. For 
example in appendix 4, lines 10-11 of page 21 contain 
the "company" and "dateTime" tags that are reduced to 
10 tags "cl" and "d2" in appendix 5 on lines 8-9 in page 
24. In these appendices 4 and 5, the position of the 
indent of an object from the beginning of the line 
defines the hierarchical dependence of this object. 

Conversely, in an advantageous variant of the 
15 invention, the import routine comprises a decompression 
program (61) to generate a decompacted form of a 
description file (401) in the XML language, starting 
from a compacted XML file (501) stored in the memory 
(50) of the automation equipment. The decompression 
20 program (61) comprises a step to execute the 
decompaction algorithm (603) adapted to XML files to 
obtain a file in reduced XML format (602), then a step 
to recreate the source tags (Tags) using the 
transformation mechanism (604) by applying the 
25 stylesheet (601) to the reduced XML file (602) . 

The application stored in an XML description file 
(401) on the programming station is modelled by the XML 
handler Hndlr (20) in the form of a tree structure 
(30) , using firstly information distributed in data 
3 0 bases (Dbl, Db2 , etc.) and in the form of a binary file 
in the memory of the programming station, and secondly 
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indexes created by the GenlnTag component (2 5) to 
access this information and to represent it in tree 
structure form. In the import direction, the tree 
structure is recreated from the XML source file (4 01) 
5 and XML grammar files (402). In the export direction, 
they are composed of XML grammar files. The XML 
handler Hndlr (20) , as shown in figure 1, communicates 
with managers (Mngl, Mng2 , etc.) of databases (Dbl, 
Db2 , etc . ) and with the tree structure management 

10 module, through notifications. 

Thus during an export, a manager (Mngl) can send a 
notification (102) "CreateNode (index, value)" 
requesting the XML handler Hndlr (2 0) to create a node 
with a determined index and a determined value. The 

15 XML handler Hndlr (20) uses index values and grammar 
files (4 02) to request the tree structure management 
module to create a node with tag name equal to the name 
defined by "tagname" and value equal to the value 
denoted by "value", through a notification (203) 

20 "CreateNode (tagname, value)". In the reverse 

direction, during the import, the manager (Mngl) 
requests the XML handler Hndlr (2 0) to send information 
to it about a node through a notification (201) 
"GetNode (index, value)". The XML handler Hndlr (20) 

25 that receives this notification examines the index and 
the corresponding tag name (Tag) in the mapping tables 
consisting of the index files (II to 14) . The XML 
handler Hndlr (20) then requests the tree structure 
management module to send it a notification (302) 

3 0 "GetNode (tagname, value)". 
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The handler (20) thus defined is installed on a 
programming station, and consequently, it can be used 
with the XML language grammar files to describe an 
automation application that can very easily be edited 
since the XML description files of the application 
(401) thus obtained are in ASCII can be edited and 
modified using any text editor. This avoids having 
specific display programs to display graphic languages 
specific to automation applications. 

Another advantage of the invention is that it can 
be used to operate old previously developed automation 
programs by converting (exporting) these programs 
formulated in databases (Dbl, Db2 , etc.) into XML 
files . 

Finally, another advantage of the XML handler 
Hndlr (2 0) is that it can export a description file 
from an application developed in the XML language into 
an application using one of the graphic automation 
description languages (LD, SFC, FBD) used in the past. 

The invention also relates to an automation 
equipment comprising a memory (50) containing the 
automation application program in the form of a binary 
file (502) that can be executed by the automation 
equipment. Starting from one or several description 
files (401) describing all or part of the application 
and expressed in a single, hierarchised and object 
oriented language, the automation equipment stores one 
or several files in compacted format (501) output from 
the description file(s) (401), in addition to the 
executable file (502) , in the memory (50) , the contents 
of this (these) file(s) remaining sufficient to 
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describe part of the application considered. In the 
embodiment described, this single, hierarchised and 
object oriented language is for example the XML 
(extended Markup Language) language. 

Advantageously, this type of automation equipment 
comprises translation means such as an interpreter 
module to convert description files (401) of the 
automation application stored in the XML language into 
a binary file (502) that can be executed by the 
automation equipment. The function of this interpreter 
module is to translate the instructions describing an 
automation application formulated in the XML language, 
into instructions that can be executed by the 
proprietary operating system of the automation 
equipment. In this way, the result is automation 
equipment for which the programming language would be 
accessible using any editor installed on a PC type 
machine so that the automation designer can thus 
develop application programs for which the files would 
be stored in ASCII, regardless of the manufacturer of 
the automation equipment and the operating system used, 
provided only that the automation equipment is provided 
with the interpreter module converting XML language 
into the proprietary binary language. 

Furthermore, the automation equipment may also 
comprise decompression means so that a decompacted form 
of a description file (401) in the XML language can be 
generated starting from a compacted XML file (501) 
stored in the memory (50) of the automation equipment. 
In order to achieve this, the automation equipment 
executes a decompression program (61) like that 
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described above. The decompression program (61) 

includes a step to execute a decompaction algorithm 
adapted to XML files, and then a step to recreate the 
source tags (Tags) by the application of a stylesheet 
(601) . The decompression program (61) and the 

stylesheet (601) are stored in the memory (50) of the 
automation equipment. 

In this way, a programming station without 
anything installed on it can be connected directly to 
automation equipment and can retrieve an automation 
application through description files in the XML 
language . 

Graphic automation languages can thus be described 
in a standard manner in ASCII. Standardizing a grammar 
in this way enables an exchange of application programs 
between operating systems and programming workshops 
made by different manufacturers. 

Since programming in XML is independent of a 
graphic technology and is independent of Microsoft 
Windows or any graphic library or even a graphic format 
(JPEG, BMP, etc.) the invention can be used to generate 
standard application programs that can be installed on 
the different platforms. The invention thus enables 
XML generators to automatically generate automation 
application programs. 

Finally, the invention facilitates the exchange of 
data in the form of XML files with CAD and Supervision 
software . 

It will be obvious to experts in the subject that 
this invention can be used in many other specific 
embodiments without departing from the scope of the 
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invention as claimed; Consequently, the embodiments 
given herein must be considered as illustrations but 
may be modified within the domain defined by the scope 
of the appended claims. 
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APPENDIX 1 

DTD description of the grammar of the Ladder language 

5 <!-- 

<! ENTITY % commonElements SYSTEM " commonElements . dtd" > 

%commonElements ; 

--> 

<! ELEMENT LDSource (networkLD , textbox* )> 
10 < ! ATTLIST LDSource sectionSize CDATA #IMPLIED > 
< ! ELEMENT networkLD (typeLine+ , FBLink* )> 

<! ELEMENT typeLine (emptyLine | (contact | Hlink | Vlink | coil | 
control | short Circuit | emptyCell | Calls | FFBExpression j 
compareBlock | operateBlock) *> 
15 < ! ATTLIST typeLine label CDATA #IMPLIED > 

< ! ELEMENT emptyLine EMPTY> 

<! ELEMENT contact EMPTY > 

<! ATTLIST contact typeContact ( openContact | 

closedContact | 
2 0 PContact | 

Ncontact ) #REQUIRED 
ContactVariableName CDATA # IMPLIED > 
<! ELEMENT Hlink EMPTY> 

<! ATTLIST Hlink numberCell CDATA #IMPLIED > 

2 5 <! ELEMENT Vlink EMPTY > 

<! ELEMENT coil EMPTY > 

<! ATTLIST coil typeCoil (coil | 

not Coil | 

setCoil | 

3 0 resetCoil | 

hashCoil | 
Pcoil | 

Ncoil ) #REQUIRED 
CoilVariableName CDATA #IMPLIED > 
3 5 <! ELEMENT control EMPTY > 

< ! ATTLIST control typeControl (jumpCoil | retCoil ) # RE QUI RED 

label CDATA #REQUIRED> 
<! ELEMENT shortCircuit (Vlink, (Hlink | contact j coil | calls | 
compareBlock) ) > 

40 < ! ELEMENT calls (instanceObj , typeParam? , descriptionCall? ) > 
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! ELEMENT typeParam (#PCDATA) > 

! ATTLIST typeParam enEnO CDATA #IMPLIED 

heightSize CDATA #IMPLIED > 
! ELEMENT descriptionCall (inputListFBD* , outputListFBD*) > 
! ELEMENT inputListFBD EMPTY > 

! ATTLIST inputListFBD f ormalParameterName CDATA #IMPLIED 

ef fectiveParameter CDATA #IMPLIED 
! ELEMENT outputListFBD EMPTY > 

! ATTLIST outputListFBD f ormalParameterName CDATA #IMPLIED 

ef fectiveParameter CDATA #IMPLIED 
! ELEMENT FBLink (obj Position, ob j Position+) > 
! ATTLIST FBLink from CDATA # REQUIRED 

to CDATA # REQUIRED > 
! ELEMENT compareBlock (#PCDATA) > 
! ELEMENT FFBExpression (# PCDATA) > 
! ELEMENT operateBlock (#PCDATA) > 
[ELEMENT emptyCell EMPTY > 

SATTLIST emptyCell cellNbr CDATA #IMPLIED > 

! ELEMENT textbox (obj Posit ion) > 

! ATTLIST textbox dimH CDATA # REQUIRED 
dimW CDATA #REQUIRED 
textBox NMTOKENS #IMPLIED > 



DTD description of the gr ammar of the SFC language 

< ! --< iENTITY % commonElements SYSTEM "commonElements . dtd" > 

%commonElements ; 

--> 

<! ELEMENT SFCSource (SFCHeader, SFCPage) > 
<! ELEMENT SFCHeader EMPTY > 

< ! ATTLIST SFCHeader task CDATA #IMPLIED 

graphName CDATA #IMPLIED > 
<! ELEMENT SFCPage (networkSFC* ) > 

< ! ELEMENT networkSFC ((step | jump | transition | SFCLinkObj ect | 

commentSFC) * , linkSFC* ) > 

< ! ELEMENT step (obj Position, action*) > 

<! ATTLIST step stepName NMTOKEN #IMPLIED 

stepType (initialStep | step | macroStep | inStep | 
outstep) #FIXED ' step ' > 
< ! ELEMENT action (actionName) > 

<! ATTLIST action qualifer (PI | N | PO | R | S | L | D | P | DS) 
#REQUIRED 

tValue CDATA #IMPLIED > 
<! ELEMENT actionName (#PCDATA) > 
< ! ELEMENT jump (obj Position) > 
<! ATTLIST jump stepName CDATA #IMPLIED > 

< ! ELEMENT transition (objPosition, transitionCondition?) > 

< ! ATTLIST transition trans itionName CDATA # IMPLIED > 

< ! ELEMENT transitionCondition (transitionName | variableTransition 

| boolLitteral) > 

<! ELEMENT transitionName (#PCDATA) > 

< ! ELEMENT variableTransition (#PCDATA) > 

<! ELEMENT boolLitteral EMPTY > 

< ! ATTLIST boolLitteral boolLitteral (0 | 1) #IMPLIED > 
< ! ELEMENT SFCLinkObj ect (obj Position) > 

<! ATTLIST SFCLinkObj ect width CDATA #IMPLIED 

relativePos CDATA #IMPLIED 

SFCLinkObj ectType (ABranch | PBranch | 

AJoint | P Joint) #REQUIRED > 

< ! ELEMENT commentSFC ( # PCDATA | obj Position) *> 
<! ATTLIST commentSFC height CDATA #IMPLIED 

width CDATA #IMPLIED > 
< ! ELEMENT linkSFC (obj Position, obj Position+) > 
<! ATTLIST linkSFC typeObj ectFrom (initialStep | 

step | 

macroStep | 

stepln | 

transition | 

ABranch | 

PBranch j 

AJoint | 

PJoint ) # REQUIRED 
TypeObj ectTo (initialStep | 

step | 
macroStep | 
stepOut | 



transition | 
AB ranch | 
PBranch j 
A Joint | 
P Joint | 

jump ) # REQUIRED 
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APPENDIX 3 



DTD description of the grammar of the FBD language 



<!--<!ENTITY % commonElements SYSTEM "commonElements . dtd"> 

%commonElements ; 

--> 

< ! ELEMENT FBDSource (networkFBD+) > 

< ! ELEMENT networkFBD ( (FFBBlock | textBoxFBD | labelObject 
commentObjectFBD |linkFBD)*, jumpObj ect?) > 

< [ELEMENT FFBBlock (instanceObj , typeParamFBD, objPositic 
descriptionFBD?) > 

<! ELEMENT typeParamFBD (#PCDATA) > 

< ! ATTLIST typeParamFBD enEnO CDATA #IMPLIED 

heightSize CDATA #IMPLIED > 
< ! ELEMENT descriptionFBD (input Variable* , output Variable*) > 
< ! ATTLIST descriptionFBD execOrder CDATA #IMPLIED > 
< ! ELEMENT inputVariable EMPTY> 

<! ATTLIST inputVariable f ormalParameterName CDATA #IMPLIED 
effectiveParameter CDATA #IMPLIED 
invertedPin (TRUE | FALSE) #IMPLIED> 

<! ELEMENT outputVariable EMPTY > 

< ! ATTLIST outputVariable f ormalParameterName CDATA #IMPLIED 
effectiveParameter CDATA #IMPLIED 
invertedPin (TRUE | FALSE) #IMPLIED > 

<! ELEMENT labelObject (obj Position) > 

< ! ATTLIST labelObject label CDATA #IMPLIED > 

< ! ELEMENT jumpObject (obj Position) > 

<! ATTLIST jumpObject label CDATA #IMPLIED > 

< ! ELEMENT textBoxFBD (#P CDATA | obj Position) *> 

< [ATTLIST textBoxFBD width CDATA #IMPLIED 

height CDATA # IMPLIED > 

< [ELEMENT commentObjectFBD (# PCDATA | obj Position) * > 

< [ELEMENT linkFBD (obj Position , obj Position, obj Position*) > 

< [ATTLIST linkFBD origineLink CDATA #IMPLIED 

destinationLink CDATA #IMPLIED > 
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APPENDIX 4 

Uncompacted source XML of a given automation application 
<?xml version = "1.0"?> 

<!DOCTYPE FEFExchangeFile SYSTEM "entity_global . dtd> 

<?xml- stylesheet type="text/xsl" href ="entity_globalR.xsl" ?> 

< FEFExchangeF i 1 e > 

<headerBlock company = "Schneider Automation" > 

<dateTime year = "2 000" month = "8" day = "21" hours = "10" 
minutes = "16" seconds = "38"/> 
</headerBlock> 

<applicationBlock name = "UNITY-Station" version = "0.0.000"/> 
<I0Conf constructorName = "Constructor name" gamme 
"Constructor gamme "> 
<PLC> 

<partltem partNumber = "TSX TOTO" code = " 123456 "/> 
<equiplnf o/> 
<conf igPremium> 

<I0Bus name = "Bus Titi"> 
<rackBusX> 

<partltem partNumber = "Rack hjhj" code = 
"45567"/> 
<equipInfo/> 
</rackBusX> 
</lOBus> 
<conf igModule> 

<channel channel = "voie45"/> 
</conf igModule> 
< / conf igPremium> 
</PLC> 
</IOConf > 
<logicConf > 

<resource resName = "Ex: (TSX 5720 V3.0)" resident = "Ex: 
(TSX 5720) "> 

<taskDesc task = "MAST" taskType = "cyclic" valueType = 
"0" maxExecTime = "50"> 

<sectionDesc sectionName = "toto"/> 
</taskDesc> 
</resource> 
</logicConf > 
<program> 

<programHeader/ > 
<LDSource> 

<networkLD> 

<typeLine label = "LabelBegin"> 

<contact contactVariableName = "%I1" typeContact 

= " openCont act " / > 

<HLink numberCell = "l"/> 

<contact contactVariableName = "%I2" typeContact 
= "closedContact"/> 

<coil coilVariableName = "%Q36" typeCoil 

"coil"/> 
</typeLine> 
<typeLine> 

<contact contactVariableName = "ACT1" 

typeContact = "PContact"/> 
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<HLink number-Cell = "3"/> 

<contact contactVariableName = "hjhkh" 
typeContact = "openContact " / > 

<coil coilVariableName = "coill" typeCoil = 
5 "notCoil"/> 
</typeLine> 
<typeLine> 

<contact contactVariableName = "ACT2" 

typeContact = "NContact'*/> 
10 <contact contactVariableName = "ACT3 " 

typeContact = "closedContact"/> 
<HLink numberCell = "2"/> 

<coil coilVariableName = "coill" typeCoil = 
"setCoil"/> 
15 </typeLine> 
<typeLine> 

H' <contact contactVariableName = "LampeTest2" 

P typeContact = "openContact "/> 

O <HLink numberCell = "l"/> 

VI 2 0 <coil coilVariableName = "coil2" typeCoil = 

jyj "resetCoil"/> 
ri\ </typeLine> 
LI <typeLine> 

H <HLink numberCell = "l"/> 

2 5 <contact contactVariableName = "LampeTestl" 

* typeContact = "closedContact"/> 

. <coil coilVariableName = "coil3" typeCoil = 

fU "PCoil"/> 
Ni </typeLine> 
y.j 3 0 <typeLine> 

f- <contact contactVariableName = "coill" 

§«H typeContact = "closedContact"/> 

% ~' <contact contactVariableName = "Coil4" 

typeContact = "openContact "/> 
35 <coil coilVariableName = "coil4" typeCoil = 

"NCoil"/> 
</typeLine> 
</networkLD> 
</LDSource> 
4 0 </program> 

<program name = "SectionFBD"> 
<programHeader> 

<dateTime year = "20 00" month = "8" day = "7" hours = 
"16" minutes = "58" seconds = "15"/> 
45 <comment>Commentaire du FBD</comment> 

</programHeader> 
<FBDSource> 

<networkFBD> 

<textBoxFBD>This section is used to demonstrate on 
50 instance of LIGHTS</textBoxFBD> 

</networkFBD> 
<networkFBD> 

<FFBBlock> 

55 <instanceObj name = ".1.1" type = "AND_BOOL"/> 

<typeParamFBD/ > 

•cobjPosition posX = "10" posY = "2"/> 
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<descriptionFBD execOrder = "1"> 

<input Variable f ormalParameterName = "II" 
ef f ectiveParameter = "LampTestl"/> 
<inputVariable formal ParameterName = "12" 
eff ectiveParameter = "LampTest2"/> 
</ descriptionFBD> 
</FFBBlock> 
<FFBBlock> 

<instanceObj name = "FBI_1_2" type = "LIGHTS "/> 
<typeParamFBD/> 

<obj Position posX = "10" posY = "9"/> 

<descriptionFBD execOrder = "3"/> 
</FFBBlock> 
<FFBBlock> 

<instanceObj name = ".1.4" type = "OR_BOOL"/> 
< type Par amFBD/ > 

<obj Position posX = "30" posY = "2"/> 
<descriptionFBD execOrder = "4"> 

<outputVariable f ormalParameterName = "Ql" 
eff ectiveParameter = "out4"/> 
</descriptionFBD> 
</FFBBlock> 
<FFBBlock> 

<instanceObj name = ".1.5" type = "OR_BOOL"/> 
<typeParamFBD/ > 

<obj Position posX = "30" posY = "9"/> 
<descriptionFBD execOrder = "6"> 

<outputVariable f ormalParameterName = "Ql" 
ef fectiveParameter = "out5"/> 
</descriptionFBD> 
</FFBBlock> 
<FFBBlock> 

<instanceObj name = ".1.3" type = "OR_BOOL"/> 
<typeParamFBD/ > 

<obj Position posX = "10" posY = "30"/> 
<descriptionFBD execOrder = "2"> 

<inputVariable f ormalParameterName = "II" 
eff ectiveParameter = "Mamiall"/> 
<inputVariable f ormalParameterName = "12" 
eff ectiveParameter = "ACT4"/> 
</descriptionFBD> 
</FFBBlock> 
/networkFBD> 
networkFBD> 

<linkFBD origineLink = ".l.l.Ql" destinationLink = 

" .1.4 .Il"> 

■cobjPosition posX = "17" posY = "5"/> 
<obj Position posX = "3 0" posY = "5"/> 

</linkFBD> 

<linkFBD origineLink = "FBI_1_2" destinationLink = 

".1.4.I2"> 

<obj Position posX = "18" posY = "12"/> 
<objPosition posX = "22" posY = "12"/> 
<objPosition posX = "22" posY = "6"/> 
<obj Position posX = "30" posY = "6"/> 

</linkFBD> 
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<linkFBD origineLink = ".1.1.Q1" destinationLink = 

».1.5.I1"> 

<obj Position posX = "17" posY = "5"/> 
<obj Position posX = "28" posY = "5"/> 
<objPosition posX = "28" posY = "12"/> 
<obj Position posX = "3 0" posY = "12"/> 

</linkFBD> 

<linkFBD origineLink 
"FBI_1_2 .S"> 

<obj Position posX = "16" posY 
<objPosition posX = "18" posY 
<obj Position posX = "18" posY 
<obj Position posX = "6" posY = 1 
<objPosition posX = "6" posY = 1 
<obj Position posX = "10" posY = 
</linkFBD> 
</networkLD> 
</FBDSource> 
</program> 

<dataBlock name = ""> 

<variables typeData = "BOOL 
directAddress = "%Ml"/> 

<variables typeData = "BOOL" instanceName = "LampTest2 " /> 
<variables typeData = "BOOL" instanceName = "0UT4"/> 
■cvariables typeData = "BOOL" instanceName = "0UT5"/> 
<variables typeData = "BOOL" instanceName = "ACT4"/> 
<variables typeData = "BOOL" instanceName = "Manuall"/> 
</dataBlock> 
< / FEFExchangeFi le > 



. 1.3.Q1" destinationLink 



»33»/> 
"33"/> 
"19"/> 

"19"/> 

"7"/> 
»7«/> 



instanceName = 
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APPENDIX 5 

Reduced source XML of automation app lication in appendix 4 

?xml version = "1.0" encoding = "UTF-8"?> 
fl6> 

<hl cl=" Schneider Automation" > 

<d2 yl="2000" ml="8" dl="21" hl="10" m2="16" sl="38"/> 
</hl> 

<al nl="UNITY-Station" vl="0 . 0 . 000"/> 
<I2 c3="Constructor name" gl="Constructor gamme"> 
<P5> 

<p8 p9="TSX TOTO" c5= " 12 3456 " / > 

<el/> 
<c8> 

<I4 nl="Bus Titi"> 
<r2> 

<p8 p9="Rack hjhj" c5="45567"/> 

<el/> 
</r2> 
</l4> 
<c9> 

<cl0 cll="voie45"/> 
</c9> 

</c8> 
</P5> 
</l2> 
<17> 

<rl6 rl7="Ex: (TSX 5720 V3.0)" rl8="Ex: (TSX 5720) "> 
<tl4 tl5="MAST" tl6="cyclic" v8="0" ml4="50"> 

<Sl9 s20="toto"/> 
</tl4> 
</rl6> 
</17> 
<p3 5> 

<p39/> 
<19> 

<nl7> 

<tl9 18="LabelBegin"> 

<c23 t2 0="0penContact" c24="%Il"/> 
<H13 nl8="l"/> 

<c23 t20="ClosedContact" c24="%I2"/> 

<c25 c26="%Q36"/> 
</tl9> 
<tl9> 

<c23 t20="PContact" c24="ACTl"/> 
<H13 nl8="3"/> 

<c23 t2 0="0penContact" c24="hjhkh"/> 

<c25 c26="coill"/> 
</tl9> 
<tl9> 

<c23 t20="NContact" c24="ACT2"/> 

<c23 t20="ClosedContact" c24="ACT3"/> 

<H13 nl8="2"/> 

<c25 c26="coill"/> 
</tl9> 
<tl9> 
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<c23 t20="openContact" c24="LampeTest2"/> 

<H13 nl8="l"/> 

<c25 c26="coil2"/> 
</tl9> 
<tl9> 

<H13 nl8="l"/> 

<c23 t2 0="ClosedContact" c24="LampeTestl"/> 

<c25 c26="coil3"/> 
</tl9> 
<tl9> 

<c23 t20=" ClosedContact " c24="coill"/> 
<c23 t2 0="OpenContact" c24=" coil4"/> 
<c25 c26="coil4"/> 
</tl9> 
</nl7> 
</l9> 
</p35> 

<p35 nl="SectionFBD"> 
<p3 9> 

<dl yl="2000" ml="8" hl="16" m2="58" sl="15"/> 

<c2>Commentaire du FBD</c2> 
</p39> 
<F12> 

<nl9> 

<t3 8>This section is used to demonstrate on 

instance of LIGHTS</t38> 
</nl9> 
<nl9> 

<F13> 

<il nl=".l.l" tl="AND_BOOL"/> 
<t27/> 

<ol pl="10" p2="2"/> 
<d21 el8="l"> 

<il4 fl4="Il" el6="LampTestl"/> 
<il4 fl4="I2" el6="LampTest2"/> 
</d21> 
</F13> 
<F13> 

<il nl="FBI_l_2" tl="LIGHTS"/> 
<t27/> 

<ol pl="10" p2="9"/> 

<d21 el8="3"> 
</F13> 
<F13> 

<il nl=".1.4" tl="OR_BOOL"/> 
<t27/> 

<ol pl="30" p2="2"/> 

<d21 el8="4"> 

<o6 fl4="Ql" el6="out4"/> 

</d21> 
</F13> 
<F13> 

<il nl=".1.5" tl="OR_BOOL"/> 
<t27/> 

<Ol pl="30" p2="9"/> 
<d21 el8="6"> 

<o6 fl4="Ql" el6="out5"/> 
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</d21> 
</F13> 
<F13> 

<il nl=".1.3" tl="OR_BOOL"/> 
<t27/> 

<ol pl="10" p2="30"/> 
<d21 el8="2"> 

<il4 fl4="Il" e 16= "Manual l"/> 
<il4 fl4="I2" el6="ACT4"/> 
</d21> 
</F13> 
</nl9> 
<nl9> 

<113 o7=".l.l.Ql" d22=" . 1.4 .Il"> 
<Ol pl="17" p2="5"/> 
<ol pl="30" p2="5"/> 

</113> 

<113 o7="FBI_l_2" d22=" . 1.4 .I2"> 
<ol pl="18" p2="12"/> 
<ol pl="22" p2="12"/> 
<Ol pl="22" p2="6"/> 
<ol pl="30" p2="6"/> 

</113> 

<113 o7=" .1.1.Q1" d22=" .1.5.I1"> 
<ol pl="17" p2="5"/> 
<ol pl="28" p2="5"/> 
<ol pl="28" p2="12"/> 
<ol pl="30" p2="12"/> 

</113> 

<113 o7=".1.3.Ql" d22=" FBI_1_2.S"> 
<ol pl="16" p2="33"/> 
<ol pl="18" p2="33"/> 
<Ol pl="18" p2="19"/> 
<ol pl=»6" p2="19"/> 
<ol pl="6" p2="7"/> 
<ol pl="10" p2="7"/> 
</113> 
</nl9> 
</F12> 
</p35> 
<d23 nl=""> 

<vlO ilO="LampTestl" dl5="%Ml" tl7="BOOL"/> 
<vlO ilO="LampTest2" tl7="B00L"/> 
<vlO ilO="OUT4" tl7="BOOL"/> 
<vlO ilO="OUT5" tl7="BOOL"/> 
<V10 ilO="ACT4" tl7="B00L"/> 
<vlO ilO="Manuall" tl7="BOOL"/> 
</d23> 

</fl6> 
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APPENDIX 6 

Extract from an XLS stylesheet use d to reduce tags 
<?xml version ="1.0"?> 

<xsl : stylesheet xmlns :xsl= httP: //www.w3 . or a/1999/XSL/Transf orm 
version="1.0"> 

<xsl:output method = "xml" indent = "yes"/> 

<xsl : strip-space elements = "*"/> 



<!-This file contains an XSLT transformation stylesheet which 
constructs a result tree from a number of XML sources by 
reordering and adding arbitrary structure. This file 

automatically generated by IBM's Visual XML Transformation (V-XMLT 
tool) . 

======================================= ==================== - - > 

< J --Note although this file should not be edited in general, 
you want to adjust the paths of the XML sources or change the 
element of the resulting XML source. This can be accomplished 
updating the sections "XML Sources" and "Root Element Template" 
respectively. 



<!__ XML sources The 

"XML Sources" section accomplishes two things: it specifies the 
input XML sources and relates the root node of each source to a 
global variable for access throughout the stylesheet. 

=========================================================== " " > 

<xsl: variable name = "vl" select = "document 
('D: /XML/dtd/unity/FEFSample.xml' ) "/> 

<!-- Root Element Template 

<!--The "Root Element Template" section specifies which 
template will be invoked first thus determining the root element 
of the result tree. Note if the root element is a newly-defined 
element that is not associated with the input XML sources, then 
the template is invoked by name. Otherwise, the template is 
invoked by applying matching template rules in XSLT. 



<xsl : template match ="/"> 

<xsl:apply-templates select = "$vl//FEFExchangeFile [1] "/> 
</xsl : template> 
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<!-- Remaining Templates > 

<!-- The remaining section defines the template rules. The 
last template rule is a generic identity transformation used for 
moving complete tree fragments from an input source to the result 
tree . 

<!-- Note it should not be necessary to edit the remaining 
section of this file!> 

<!-- Composed element template --> 
<xsl : template match = "obj Position" > 
<ol> 

<xsl:if test ="@posX"> 

<xsl: attribute name = "pl"> 
<xsl: value-of select = "@posX"/> 

</xsl : attribute> 
</xsl:if > 

<xsl:if test ="@posY"> 

<xsl : attribute name = "p2"> 
<xsl: value-of select = "@posY"/> 

</xsl: attribute> 
</xsl:if > 

<xsl : apply-templates select = "* | comment () | processing- 
instruction ( ) |text()"/> 
</ol> 
</xsl :template> 

<!— Rename transformation template --> 

<xsl : template match = "headerBlock w > 
<hl> 

<xsl:if test ="@company"> 

<xsl: attribute name = "cl"> 

<xsl : value-of select = "@company"/> 

</xsl: attribute> 
</xsl:if > 

<xsl : apply-templates select = "* | comment () | processing- 
ins truction ( ) | text ( ) " / > 
</hl> 
</xsl : template> 

<!— Composed element template --> 

<xsl : template match = "dateTime *> 
<dl> 

<xsl:if test ="@year"> 

<xsl : attribute name = ™yl"> 

<xsl: value-of select = "@year"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@month"> 

<xsl: attribute name = "ml"> 
<xsl: value-of select = "@month"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@day"> 
<xsl : attribute name = "dl"> 
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<xsl: value-of select = "@day"/> 
</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@hours"> 

<xsl : attribute name = "hl"> 
<xsl: value-of select = "@hours"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@minutes"> 

<xsl: attribute name = "m2"> 

<xsl: value-of select = "@minutes"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@seconds"> 

<xsl: attribute name = "sl"> 
<xsl: value-of select = "©seconds" /> 

</xsl : attribute> 
</xsl:if > 

<xsl:if test ="@dateTime"> 

<xsl : attribute name = "d2"> 
<xsl: value-of select = "@dateTime"/> 

</xsl: attribute> 
</xsl:if > 

<xsl : apply-templates select = "* | comment () | processing- 
instruction () |text()"/> 
</dl> 
</xsl :template> 

<!— Composed element template --> 

<xsl : template match = "applicationBlock "> 
<al> 

<xsl:if test ="@name"> 

<xsl: attribute name = "nl"> 
<xsl: value-of select = "@name"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@version"> 

<xsl: attribute name = "vl"> 
<xsl: value-of select = "@version"/> 

</xsl: attribute> 
</xsl:if > 

<xsl : apply-templates select = "* | comment () | processing- 
instruction () |text()"/> 
</al> 
</xsl : template > 

<!-- Rename transformation template --> 

<xsl : template match = "comment "> 
<c2> 

<xsl : apply-templates select = "* | @* | comment () [processing- 
ins truct ion ( ) | text { ) " / > 
</c2> 
</xsl : template> 

<! --Composed element template --> 



<xsl : template match = "properties"> 
<p2> 
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<xsl:if test ="@protectionInfo"> 

<xsl : attribute name = "p4"> 
<xsl: value-of select = "©protectionlnf o"/> 

</xsl: attribute> 
</xsl:if > 

<xsl : apply-templates select = "* | comment () (processing- 
instruction ( ) | text ( ) " / > 
</p3> 
</xsl : template> 

<!— Composed element template --> 

<xsl : template match = "instanceObj "> 
<il> 

<xsl:if test ="@address"> 

<xsl: attribute name = "a2"> 

<xsl: value-of select = "©address" / > 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@name"> 

<xsl : attribute name = "nl"> 
<xsl: value-of select = "@name"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="®type"> 

<xsl: attribute name = "tl"> 
<xsl : value-of select = "@type"/> 

</xsl : attribute> 
</xsl:if > 

<xsl : apply-templates select = "* j comment () | processing- 
instruction () |text()"/> 
</il> 
</xsl :template> 

<!— Rename tranf ormation template --> 

<xsl : template match = "descCard"> 
<d4> 

<xsl : apply-templates select = "* | @* | comment () | processing- 
instruct ion ( ) | text ( ) " / > 
</d4> 
</xsl : template> 

<!— Composed element template --> 

<xsl : template match = "IOConf"> 
<I2> 

<xsl:if test ="@constructorName" > 

<xsl: attribute name = "c3"> 

<xsl: value-of select = "@constructorKame"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@gamme"> 

<xsl: attribute name = "gl"> 

<xsl: value-of select = "@gamme"/> 

</xsl: attribute> 
</xsl:if > 

<xsl : apply-templates select = "* | comment () [processing- 
instruction ( ) |text()"/> 
</I2> 
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</xsl : template> 

<!— Composed element template --> 

<xsl : template match = "PLC"> 
<P5> 

<xsl: if test ="@cartridge"> 

<xsl: attribute name = "c4"> 
xsl: value-of select = "©cartridge" /> 

</xsl : attribute> 
</xsl:if > 

<xsl:if test ="@autorun"> 

<xsl: attribute name = "a3"> 
xsl: value-of select = "@autorun"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@alarm"> 

<xsl: attribute name = "a4"> 
xsl: value-of select = "@alarm"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@runStop"> 

<xsl: attribute name = "rl"> 
xsl: value-of select = "@runstop"/> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="®protection" > 

<xsl: attribute name = "p6"> 
xsl: value-of select = "©protection" /> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@MWInitZero"> 

<xsl: attribute name = "m3"> 
xsl: value-of select = "©MWInitZero" /> 

</xsl: attribute> 
</xsl:if > 

<xsl:if test ="@progMWSave" > 

<xsl : attribute name = "p7"> 
xsl: value-of select = "©progMWSave" /> 

</xsl : attribute> 
</xsl:if > 

<xsl : apply- templates select = "* | comment () [processing- 
instruction () |text()"/> 
</p5> 
</xsl : template> 

<!— Composed element template --> 



<xsl : template match. = "partltem"> 
<p8> 

<xsl:if test =" ©vendorName " > 
50 <xsl: attribute name = "v2"> 

xsl: value-of select = "©vendorName" /> 
</xsl : attribute> 
</xsl:if > 

<xsl:if test ="@partNumber"> 
55 <xsl: attribute name = "p9"> 

xsl: value-of select = "©partNumber" /> 
</xsl: attribute> 
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</xsl:if > 

<xsl:if test ="@version"> 
<xsl: attribute name = "vl"> 
xsl: value-of select = "@version"/> 
5 </xsl: attribute> 

</xsl:if > 

<xsl:if test ="@description" > 
<xsl: attribute name = u d5"> 
xsl: value-of select = "©description" /> 
10 </xsl: attribute> 

</xsl:if > 

<xsl:if test ="@code"> 
<xsl: attribute name = "c5"> 
xsl: value-of select = "@code"/> 
15 </xsl: attribute> 

</xsl:if > 

<xsl : if test ="@family"> 
<xsl: attribute name = "fl"> 
xsl: value-of select = "@family"/> 
2 0 </xsl: attribute> 

</xsl:if > 

<xsl:if test ="@class"> 
<xsl : attribute name = "c6"> 
xsl: value-of select = "@class"/> 

2 5 </xsl: attribute> 

</xsl:if > 

<xsl : apply- templates select = "* | comment () |processing- 
instructionO |text()"/> 
</p8> 

3 0 </xsl : template> 

<!— Composed element template --> 



